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REMARKS 

Claims 1-20 were originally filed in the present application. 

Claims 1-20 are pending in the present application. 

Claims 1-20 were rejected in the July 19, 2007 Office Action. 

No claims have been allowed. 

Claims 1-20 remain in the present application. 

Reconsideration of the claims is respectfully requested. 

In the July 19, 2007 Office Action, the Examiner rejected Claims 1-20 under 35 U.S.C, 
§ 103(a) as being unpatentable over U.S. Patent No. 7,027,426 B2 to Billharts, (hereinafter, simply 
c *Billharts") in view of U. S. Patent Application Publication No. 2002/0039357 to Lipasti, et ah 
(hereafter, simply "Lipasti"). 

In ex parte examination of patent applications, the Patent Office bears the burden of 
establishing optima facie case of obviousness. MPEP § 2142, p. 2100-133 (8th ed. rev. 4, October 
2005). Absent such a prima facie case, the applicant is under no obligation to produce evidence of 
nonobviousness. Id. To establish a prima facie case of obviousness, three basic criteria must be 
met: Id. First, there must be some suggestion or motivation, either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Id. Second, there must be a reasonable expectation of success. Id. 
Finally, the prior art reference (or references when combined) must teach or suggest all the claim 
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limitations. Id, The teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, and not based on applicant's disclosure. 
Id. 

Claim 1 requires 

1, (Original) For use in a mobile ad hoc network 
formed by a plurality of mobile ad hoc network (MANET) nodes, a 
first MANET node capable of collecting route infoimation associated 
with a first route from a source MANET node to a destination 
MANET node, said first MANET node comprising; 

a radio frequency (RF) transceiver capable of wirelessly 
communicating with other ones of said plurality of MANET nodes 
according to an ad hoc on-demand vector (AODV) protocol; and 

a controller capable of receiving incoming data packets from 
said RF transceiver and sending outgoing data packets to said RF 
transceiver, wherein said controller receives a Path Marker Request 
message generated by said source MANET node and retrieves first 
route topology data associated with said first route from said first 
Path Marker Request message, said route first topology data 
identifying all intermediate MANET nodes in said first route coupling 
said first MANET node to said source MANET node. 



The Examiner alleges that the claimed "controller" is met by Billhartz's controller 44 that 
includes a "route discovery unit 50". Individual nodes 30 include controller 44, 

No art of record, alone or in combination, teaches or suggests that the controller receives 
a Path Marker Request message generated by the source MANET node and retrieves first route 
topology data associated with a route from the first Path Marker Request message, or that the 
first route topology data identifies all intermediate MANET nodes in the route coupling the first 
MANET node to the source MANET node, as claimed. 
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The Examiner alleges that this is taught by Billhartz at col, 5, lines 3-31: 

The method begins (block 100) and includes transmitting a route 
requests RREQ from the source node S to discover routing to the 
destination node D over multiple channels, as indicated at block 102 
in FIG. 8. the source node S does not currently know what channel 
the destination node D is normally on. In the example illustrated in 
FIG. 1 , the source node sends the route request RREQ to intermediate 
nodes A-C. The source node S and node C may normally be on a first 
channel, node B may normally be on a second channel, and node A 
may normally be on yet a third channel, for example, So, the source 
node S sends the route request RJREQ over all the existing channels 
that the network is currently operating on to reach all nodes 30 within 
one-hop. Preferably, the route request RREQ would include a source 
node channel identifier indicating what channel the source node S is 
on. 

Separately, on each channel, route discovery proceeds as usual (FIG. 
2). Each intermediate node A, B and C determines whether the node 
can support the route request RREQ. If the node cannot support the 
particular request RREQ, then the request is denied or simply not 
. forwarded by the node. If the node, for example node A, can support 
the particular request RREQ, then the node forwards the route request 
RREQ to other intermediate nodes, e.g node H, on all channels and 
temporarily reserves node resources for that route request if the 
request is for traffic other than best-effort For best-effort, no 
resources necessarily need be reserved. The route request RREQ is 
• eventually forwarded to the destination node D. 



The only thing taught as being sent and received here is route request RREQ. Route 
request RREQ is not taught or suggested to be a "path marker request message" as claimed, or an 
equivalent of the path marker request message. Nothing in the art of record teaches or suggests 
that first route topology data associated with a route can be retrieved from the route request 
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RREQ, as would be required. As the Examiner notes, Billhartz only discloses that RREQ 

includes a "source node channel identifier" (col. 5, lines 16-17). 

The Examiner instead refers to Lipasti paragraph 0010, indicating that topology" is read 

as touting addresses* 7 : 

[0010] According to a preferred embodiment of the invention, the 
routing addresses are composed from IP addresses. This provides the 
great advantage that there is no need for a protocol, such as ARP, 
arranging mapping from network layer addresses to data link layer 
addresses. This reduces the bandwidth-intensive broadcast traffic in 
the mobile ad hoc networks. 

Lipasti only appears to teach, in relevant part, of using additional source/destination 
routing addresses and using these for routing instead of network layer addresses or data link layer 
addresses. This does not discuss anything about a network route topology at all, and certainly 
nothing in Lipasti specifically discusses a route topology. A network address, or even a 
collection of addresses, is not a topology. 

Further, even if Lipasti's addresses were somehow a 'topology", nothing in the art of 
reference teaches or suggests that Lipasti's addresses can or should be used as part of Billhartz's 
route request RREQ, or that these addresses could be extracted from the RREQ. To meet the 
claim limitation, the controller must retrieve route topology data identifying all intermediate 
MANET nodes in said first route coupling said first MANET node to said source MANET node 
from the first Path Mark er Request message. Nothing in the art of record teaches or suggest 
anything like this. No route topology can be extracted from Billhartz's RREQ. Nothing in 
Lipasti teaches or suggests any topology can be extracted from any packet. 
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Applicant has reviewed the Examiner's response, and must respectfully note that the 
Examiner's analysis simply doesn't reach the claim limitations. Lipasti does describe source and 
destination addresses, and indicates that a routing table can include a '"next hop" address. None 
of this meets the claim requirements for the route topology data - that the data identify all 
intermediate notes in a route coupling a first node to a source node. Knowing the (t next hop" 
after the first node doesn't meet the limitation, as the fi< next hop" isn't one of the intermediate 
hops on which the packet has been received. 

More importantly, Claim 1 clearly requires that the route topology data is retrieved from 
the first oath marker request message. Even considering Lipasti 's suggestion that a node can 
have a routing table, there is no teaching or suggestion in any reference of record that any request 
message, including Billhart's RREQ, can include route topology data. It would not be sufficient 
to simply determine that route topologies were known in the art; the topology must be able to be 
retrieved from the request message in order to meet the claim limitations. 

No combination of BiUhartz and Lipasti can meet the claim limitations. 

Claim 1 1 includes similar limitations. As can be seen, no art of record, alone or in 
combination teaches or suggests the limitations of the independent claims. 

Further, nothing in Billhartz, or Lipasti, alone or in combination, teaches or suggests 
storing a retrieved route topology data in a route table associated with a controller, as in claims 2 
and 12, 
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Other distinctions exist, but those discussed above serve to show that all claims 
distinguish over all art of record. 

Accordingly, the Applicant respectfully requests the Examiner to withdraw the § 103 
rejection with respect to these claims. 

The Examiner is requested to telephone the undersigned to resolve any remaining issues. 
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SUMMARY 

For the reasons given above, the Applicant respectfully requests reconsideration and 
allowance of the pending claims and that this application be passed to issue. If any outstanding 
issues remain, or if the Examiner has any further suggestions for expediting allowance of this 
application, the Applicant respectfully invites the Examiner to contact the undersigned at the 
telephone number indicated below or aXjfttockler@munckbutrus.com. 

The Commissioner is hereby authorized to charge any additional fees connected with this 
communication or credit any overpayment to Deposit Account No. 50-0208. 

Respectfully submitted, 
MunckButrus/P.C 



Date: September 18, 2007 John T. Mockler 

Registration No. 39,775 

P.O. Drawer 800889 

Dallas, Texas 75380 

Phone; (972) 628-3600 

Fax: (972)628-3616 

E-mail: jmockIer@munckbutrus.com 
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